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ABSTRACT 

The  Army  Acquisition  community  has  a  significant  deficiency  in  the  amount  of  operational  expertise  to 
influence  a  particular  S&T  technology  or  acquisition  program.  As  a  result,  emerging  materiel  solutions  often  fall 
short  of  their  desired  utility  in  the  eyes  of  the  warfighter.  In  a  fiscally  constrained  environment,  the  product 
development  team  must  use  all  available  resources  in  the  most  efficient  manner  to  produce  the  highest  quality 
product  in  the  shortest  time  possible  for  the  end  user.  By  repurposing  the  information  contained  in  the  Combined 
Arms  Training  Strategies  (CATS)  task  database,  an  engineering  team  can  gain  the  operational  knowledge  and 
environment  from  the  training  tools  the  Army  uses,  requiring  less  burden  on  the  few  operational  experts  that  exist 
within  the  Acquisition  Corps.  A  process  to  accomplish  this  is  being  developed  at  TARDEC  and  has  had  early 
success  in  characterizing  vehicle  operator  behaviors  beyond  what  occurs  within  structure  of  a  vehicle. 


INTRODUCTION 

In  an  increasingly  complex  operating  environment,  cutting- 
edge  technology  can  quickly  become  the  discriminator 
between  mission  success  and  failure.  As  financial  resources 
tighten  and  more  scrutiny  is  applied  to  development 
programs,  it  becomes  more  important  to  understand  the 
operational  utility  (i.e.,  the  benefits)  of  a  technology  early  in 
the  life  cycle.  Technologies  that  cannot  show  direct  utility  to 
the  soldier  end  up  falling  below  the  cut  line  when  decisions 
are  made  to  fit  within  financial  constraints  for  a  fiscal  year. 
Ideally,  the  applicable  Training  and  Doctrine  Command 
(TRADOC)  Center  of  Excellence  (CoE)  would  develop  a 
detailed  Concept  of  Operations  and  set  of  User  requirements, 
but  this  level  of  concept  maturity  is  typically  not  available  for 
emerging  Army  Science  and  Technology  (S&T)  projects, 
especially  early  in  the  project  lifecycle.  As  a  result,  S&T 
Project  Teams  are  often  left  to  use  their  own  judgment  to 
determine  the  use  cases  and  utility  of  a  technology. 

In  this  situation,  a  weakness  in  the  Army’s  materiel 
development  lifecycle  is  observed.  The  Army  relies  on  its 
S&T  process  to  mature  cutting-edge  technologies  to  prepare 
them  for  inclusion  in  a  materiel  solution  that  will  continue 
U.S.  military  superiority.  However,  the  active  and  reserve 
forces  of  the  Army  do  not  produce  a  significant  amount  of 
degreed  engineers,  with  the  exception  of  civil  engineers.  As 
such,  the  Army  Corps  of  Engineers  is  strong  with  operational 
Army  expertise,  but  the  Army  Acquisition  community  is  left 


to  rely  on  the  civilian  engineer  workforce,  many  of  whom 
have  no  soldiering  experience. 

The  lack  of  operational  expertise  in  the  Army  Acquisition 
Corps  is  an  issue  identified  at  the  highest  levels  of  Army 
leadership.  At  the  Association  of  the  US  Army’s  Global  Force 
Symposium  the  acting  Assistant  Secretary  of  the  Army 
(Acquisition,  Logistics  &  Technology),  Katrina  McFarland, 
stated  the  Army  tends  to  jump  at  materiel  solutions  without 
fully  understanding  the  long-term  unintended  consequences. 
She  attributed  part  of  the  problem  to  the  removal  of 
operational  research  science  and  advisors  as  part  of  work 
force  downsizing.  According  to  McFarland,  “Guys  that  look 
at  the  military  part  of  war”  as  part  of  a  larger,  long-term 
picture  of  the  impact  of  new  technologies  are  needed  in  the 
acquisition  community [1]. 

As  a  result  of  these  shortcomings.  Project  Teams  are  forced 
to  scavenge  the  operational  expertise  they  need  from  the 
isolated  pockets  of  knowledge  that  do  exist  in  organizations, 
but  with  tens  or  hundreds  of  projects  occurring  at  once,  there 
is  not  enough  support  to  go  around.  Projects  that  cannot  find 
the  support  they  need  either  use  best  judgment,  or  worse,  start 
ignoring  the  operational  utility  questions  that  hover  over  head. 
These  habits  are  contributing  causes  to  why  emerging 
technologies  in  Army  S&T  have  trouble  transitioning  to 
Programs  of  Record. 
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BREAK  THE  CYCLE 

In  response  to  the  problem  above,  S&T  programs  need  a 
quick,  efficient,  and  accurate  method  to  incorporate  the  user 
perspective  and  operational  utility  of  a  technology  at  the 
program’s  onset.  The  method  needs  to  minimize  burden  to 
both  the  technology  development  team  as  well  as  the  user 
community,  while  maximizing  return  on  the  resources 
invested. 

Fortunately,  detailed  descriptions  of  the  capabilities  for  a 
particular  Army  unit  already  exist,  albeit  for  a  different 
purpose  than  Army  Acquisition.  For  years,  the  Army  has  used 
its  doctrinal  publications  as  the  basis  for  training  its  units  and 
measuring  training  proficiency.  Army  manuals  produced 
under  the  Army  Training  and  Evaluation  Program  (ARTEP) 
provided  all  the  tasks,  conditions,  and  standards  for  each 
Table  of  Organization  and  Equipment  (TOE)  unit  in  the 
Army.  With  the  digitization  of  Army  resources  over  the  past 
ten  years,  the  printed  ARTEP  manuals  have  been  replaced  by 
a  digital  system  called  Combined  Arms  Training  Strategies 
(CATS),  but  the  information  has  remained  the  same. 

While  CATS  is  intended  as  a  training  resource  for  unit 

commanders,  the  content  it  contains  is  useful  to  the 

development  community  since  it  contains  the  unit 

functionality  in  the  intended  operational  environment.  By 
manipulating  the  CATS  data  for  a  given  unit(s)  of  interest, 
using  common  system  engineering  practices,  a  doctrinal  task 
model  can  be  derived  from  TRADOC  validated  source 
material,  providing  a  traceable  linkage  to  operational  utility. 

Although  the  process  that  is  outlined  below  relies  on 
published  doctrine  from  TRADOC  and  requires  much  less 
Subject  Matter  Expert  (SME)  support  to  develop,  it  cannot  be 
executed  in  the  absence  of  any  operational  expertise. 

Application  of  CATS  is  an  art,  subject  to  the  training  and 
experience  of  the  user.  However,  CATS  enables  people 
familiar  with  Army  operational  language  to  understand  how 
all  Army  units  doctrinally  behave.  Army  officers  and  most 
Non-Commissioned  Officers  (NCOs)  have  familiarity  with 
the  CATS  tool  and  working  with  the  tasks  within  it  and  the 
tasks  and  concepts  within  it  are  common  to  the  maximum 
extent  possible.  Therefore,  to  describe  Army  Armor  doctrine, 
for  example,  the  project  team  no  longer  needs  a  former  Armor 
officer;  but,  an  officer  or  NCO  from  any  branch,  such  as 
logistics,  can  describe  Armor  doctrine  to  the  TRADOC 
standards. 

DOCTRINAL  TASK  ANALYSIS  FRAMEWORK 

This  approach  to  operational  analysis  relies  on  the  source 
data  stored  within  CATS.  By  extracting  the  CATS  data  for  a 
specific  unit  of  interest  and  applying  common  systems 
engineering  practices  to  the  data,  the  project  team  can 
generate  a  quality  operational  analysis  to  derive  their  system 
requirements  and  architecture.  The  approach  described 


herein  to  generate  analysis  using  doctrinal  training  data 
decomposes  CATS  to  an  Operational  Task  Model,  which 
decomposes  to  a  Unit  Behavior  Model  (Figure  1). 
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Figure  1:  Doctrinal  Task  Analysis  Process 

COMBINED  ARMS  TRAINING  STRATEGIES  (CATS) 

The  CATS  tool  is  available  to  anyone  who  has  a  DoD  Self- 
service  (DS)  Logon,  effectively  meaning  anyone  with  a 
Common  Access  Card  (CAC)  can  access  the  data.  CATS  is 
accessed  through  the  Army  Training  Network  (ATN) 
(https://atn.army.mil).  ATN  is  the  tool  the  unit  commander 
uses  when  developing  and  accessing  his  Mission  Essential 
Task  List  (METL),  which  is  the  key  tasks  the  unit  must 
conduct  in  wartime  to  complete  its  mission.  While  the 
approach  described  herein  specifically  refers  to  decomposing 
unit-level  collective  tasks,  it  is  important  to  note  that  the  same 
process  could  be  executed  on  individual  or  common  soldier 
tasks,  all  of  which  can  be  accessed  from  CATS  or  other  areas 
within  ATN. 

The  CATS  tool  requires  either  the  Standard  Requirements 
Code  (SRC)  for  the  specific  TOE  unit  of  interest  or  allows  the 
operator  to  browse  for  the  unit,  organized  by  proponent,  as 
shown  in  Figure  2.  Once  the  unit  is  selected,  CATS  will 
output  all  of  the  doctrinal  collective  tasks  associated  with  the 
unit.  Currently,  CATS  outputs  this  information  using  HTML 
and  hyperlinks  to  the  lower  level  functional  data.  Some 
human  effort  is  required  to  translate  the  hyperlinks  and 
HTML  data  into  a  useable  form  going  forward.  As  of  the  time 
of  publication,  TARDEC  manually  extracts  the  data  from 
CATS  and  places  it  into  Microsoft  Excel  for  manipulation. 
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While  labor  intensive,  this  process  can  be  completed  by  a 
single  person  in  3-5  days,  which  includes  some  refining  of  the 
raw  CATS  output. 


Figure  2:  The  CATS  Home  Page 

It  is  important  to  note  that  CATS  is  a  training  resource  for 
unit  commanders  and  the  functionality  to  manipulate  the  data 
is  not  required  under  its  intended  use.  Therefore,  the  labor 
intensive  task  to  extract  the  data  in  a  useable  format  for 
engineering  is  not  an  imperfection  in  the  tool  as  much  as  it  is 
a  function  of  using  the  tool  in  a  manner  other  than  designed. 
However,  an  opportunity  exists  where  the  Army  engineering 
community  can  plug  directly  into  the  database  behind  the  tool 
and  extract  the  information  using  an  integration  tool,  such  as 
the  Integrated  Systems  Engineering  Framework  (ISEF).  Such 
a  capability  would  not  only  minimize  the  labor  required  to 
extract  the  data  from  CATS,  but  enable  real-time  updates  as 
the  doctrine  is  updated  over  time. 

Understanding  the  CATS  Output:  Operational 
Task  Model 

When  reviewing  the  CATS  output  it  is  important  to  organize 
the  data  in  a  common  manner  so  it  can  be  manipulated  later. 
For  example,  the  CATS  output  for  a  Palletized  Loading 
System  (PLS)  Truck  Company  (SRC  55728R300)  reveals  99 
top-level  collective  tasks  that  are  associated  with  the  unit. 
These  top-level  collective  tasks  are  the  level  1  functions  for 
that  specific  unit. 

Within  the  documentation  for  each  level  1  function,  CATS 
describes  the  sub-tasks  required  to  complete  the  level  1 
function.  These  tasks  are  arranged  in  a  hierarchy  where  the 
sum  of  level  4  tasks  imply  completion  of  a  level  3  parent;  the 
sum  of  level  3  tasks  imply  completion  of  a  level  2  parent;  and 
so  on.  However,  logical  arguments  such  as  “if’,  “or”,  and 
“and”  may  modify  the  hierarchy  as  necessary.  CATS 
decomposes  a  level  1  task  down  to  at  least  level  4  and  in  most 
cases  level  6  or  beyond. 

The  entire  list,  when  fully  assembled  and  referenced  is 
called  the  Operational  Task  Model  and  represents  every 


function  that  the  unit,  as  a  collective  whole,  can  execute.  For 
purposes  of  understanding  the  size  of  this  model,  the  PLS 
Truck  Company  Operational  Task  Model  contains 
approximately  4,200  functions  as  has  detail  and  low  as  level 
7. 


Example  of  the  Operational  Task  Model 

The  actual  operational  tasks  for  any  Army  unit  are 
controlled  data  items,  but  for  explanation  purposes  consider 
this  simple  example  using  a  restaurant  as  the  unit  of  interest. 
Table  1  shows  an  example  Task  Model  for  a  restaurant  using 
language  and  format  similar  to  what  CATS  provides.  Only  3 
levels  are  shown  in  the  example,  but  each  task  could  be 
decomposed  to  level  7  or  beyond,  each  level  providing  more 
detail. 


Task  No. 

Task  Description 

1. 

Prepare  food  in  a  kitchen 

1.1 

Prepare  cold  food  items 

1.1.1 

Make  sandwiches  from  an  order  ticket 

1.1.2 

Make  salads  from  an  order  ticket 

1.2 

Prepare  hot  food  items 

1.2.1. 

Cook  foods  using  a  gas  grill 

1.2.2. 

Cook  foods  using  a  gas  or  electric  oven 

1.2.3 

Prepare  foods  using  a  deep  fryer 

2. 

Collect  and  serve  orders  using  wait  staff 

2.1 

Collect  customer  orders  for  service 

2.2 

Prepare  an  order  ticket  using  computer  system 

2.3 

Serve  customers  in  accordance  with  orders 

3. 

Manage  customer  complaints 

Table  1:  Example  Operational  Task  Model 


BUILDING  THE  UNIT  BEHAVIOR  MODEL 

The  Operational  Task  Model  can  be  transformed  into  a  more 
informative  unit  behavioral  model  that  accurately  describes 
the  unit  operation.  Using  SysML  to  describe  the  behaviors 
indicated  in  the  Operational  Task  Model,  the  operational 
language  of  CATS  can  be  parsed  and  translated  into  activity 
diagrams  and  use  cases  to  support  engineering  development. 
These  products  represent  two  of  the  most  important  views  of 
the  Unit  Behavior  Model. 

Behavior  Model  Activity  Diagrams 

Activity  diagrams  represent  behaviors  in  a  logical 
workflow,  akin  to  what  many  people  recognize  as  a  flow 
chart.  Development  of  activity  diagrams  is  an  important  step 
to  maturing  the  operational  understanding  of  the  unit  of 
interest  because  the  tasks  directly  out  of  CATS  does  not  imply 
any  sequencing  or  timing  in  the  tasks,  although  some 
sequencing  can  be  inferred  from  the  language  or  implied 
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through  the  hierarchy.  A  simple  activity  diagram  for  task  2  in 
the  example  Operational  Task  Model  is  shown  in  Figure  3. 


act  [Activity]  Collect  and  Serve  Orders  Using  Wait  Staff  [  Collect  and  Serve  Orders  Using  Wait  Staff  [} 

Collect 
Customer 
Orders  for 
Service 

— ;  — 

Prepare  an 
Order  Ticket 
Using  a 
Computer 

_  _  -> 

Customers  in 
Accordance 
with  Orders 

'  ks>  ' 

Figure  3:  Collect  and  Serve  Orders  Activity  Diagram 


Often  the  translation  of  Operational  Tasks  onto  one  or  more 
activity  diagrams  requires  the  operator  to  exercise  artistic 
license  in  order  to  simplify  and  streamline  the  model  without 
losing  the  intent  of  the  function.  Remembering  that  CATS 
was  developed  for  training  purposes  and  the  author  of  each 
specific  CATS  task  may  have  used  different  words  to  describe 
the  same  intent,  this  artistic  license  here  does  not  invalidate 
the  authenticity  of  the  tasks,  only  simplifies  and  condenses  the 
task  model  to  the  core  intent  of  the  task. 

An  example  where  artistic  license  is  required  is  as  follows: 
One  task  may  have  a  sub-task  stating  “Enforce  safety 
procedures  as  necessary.”  Another  may  state  “Enforce  safety 
in  accordance  with  (IAW)  AR  385-10”.  Yet  another  may  state 
“Enforce  safety  procedures  IAW  with  commander  guidance, 
SOP,  and  regulations”.  All  three  functions  are  describing  the 
same  intent  and  instead  of  complicating  the  model  with  three 
separate  functions  verbatim  from  CATS,  it  makes  more  sense 
to  condense  the  functions  into  one  common  wording  and  point 
to  it  in  three  different  activity  diagrams.  This  issue  occurs 
often  in  an  Operational  Task  Model  and  tolerance  to  condense 
like-functions  reduces  model  size  by  20-30%.  A  SME  with 
relevant  soldiering  experience  is  recommended  to 
assess/review  any  proposed  artistic  license  simplification  to 
ensure  the  core  intent  is  not  misunderstood. 

Behavior  Model  Use  Cases 

The  Operational  Task  Model  can  also  be  used  to  develop 
collective -level  use  cases.  Most  collective  tasks  sourced  from 
CATS  indicate  the  actor  or  actors  that  are  doctrinally 
associated  with  completing  the  task.  In  this  case,  developing 
a  use  case  is  simply  a  matter  of  translating  the  text  from  the 
Operational  Task  Model  into  a  Use  Case  Diagram  using 
SysML  notation. 

CATS  is  not  always  consistent,  however,  and  some  tasks  do 
not  explicitly  define  the  actors  within  the  task.  In  these  cases, 
it  is  important  to  have  a  SME  assist  with  use  case 
development  to  fill  in  the  gaps  left  by  CATS. 


Although  a  variety  of  methods  could  be  used  to  develop  use 
cases,  TARDEC  found  using  Microsoft  Excel  to  assign  actors 
to  tasks  was  a  simple  method  to  building  the  source  data  that 
could  later  be  developed  into  use  cases  if  necessary.  By 
assigning  actors  and  other  objects  in  separate  columns,  either 
through  the  CATS  data  or  using  SME  assistance,  the  use  case 
data  could  be  captured  efficiently,  minimizing  manual  labor 
and  maximizing  the  time  of  specialized  resources,  such  as 
SMEs.  In  this  format  the  data  can  be  imported  into  system 
architecture  tools  for  addition  to  the  Unit  Behavior  Model.  An 
sample  diagram  within  the  Unit  Behavior  Model  for  the  the 
example  (Table  1)  is  shown  in  Figure  3. 


Figure  4:  Collect  and  Serve  Orders  Use  Case  Diagram 


Other  SysML  Diagrams 

Depending  on  the  intended  use  of  the  model  and  the  degree 
of  complexity  other  diagrams  may  also  be  useful  to  the  project 
team  to  organize  and  describe  the  relationship  between  the 
tasks.  On  a  larger  project,  TARDEC  found  it  useful  to  use 
Block  and  Package  Diagrams  to  organize  the  high  level  tasks 
within  the  model,  where  the  package  diagram  includes  the 
Level  2  activity  diagrams  for  the  unit.  In  this  manner,  one 
could  open  the  model  and  easily  understand  the  unit’s  primary 
functions  all  in  one  view,  enabling  drill  down  through  a 
particular  task  thread  from  a  common  starting  point. 

USES  FOR  THE  DERIVED  MODELS 

At  the  most  abstract  level,  the  Unit  Behavior  Model  depicts 
a  representation  of  the  unit  operational  environment  and 
describes  how  all  the  unit  functions  work  together  to 
accomplish  the  operational  objectives  of  the  unit.  For  the 
engineering  team,  the  product’s  system  architecture  can  be 
linked  to  Unit  Behavior  Model  resulting  in  a  complete 
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functional  hierarchy  that’s  not  only  traceable  through  the 
system  being  developed,  but  also  through  the  upper  levels  of 
collective  unit  performance.  Measures  of  Effectiveness 
(MOEs)  and  Measures  of  Performance  (MOPs)  naturally  fall 
out  from  this  process  since  the  connection  between  a  system’s 
function  and  the  intended  unit  effect  is  explicitly  defined. 

While  tracing  the  system’s  functionality  to  unit  behaviors  is 
an  important  step  to  developing  a  fully  complete  and  traceable 
architecture  model,  the  Unit  Behavior  Model  has  been  useful 
in  other  aspects  of  functional  decomposition.  In  particular, 
CATS  tasks  are  very  explicit  at  describing  the  “what”  that 
needs  to  happen  to  achieve  a  certain  objective  and  virtually 
silent  about  “how”.  To  that  effect,  CATS  describes  much  of 
the  Mission  Command  functions  (the  military  art)  of  a  given 
task  and  it  is  generally  written  independent  of  hardware  or 
software  solutions.  This  solution  agnostic  approach  is 
particularly  useful  on  projects  investigating  autonomy  or  the 
removal  of  the  human  soldier  in  part  or  in  whole  from  the 
system. 

Instead  of  using  the  functional  decomposition  for  a  current 
system,  which  implies  a  human-in-the-loop  for  operation,  and 
then  backing  into  the  functions  desired  to  be  automated,  this 
approach  starts  with  a  clean  sheet  based  on  the  required  higher 
level  unit  functionality.  By  decomposing  the  unit 
functionality  into  the  system  of  interest,  the  engineering  team 
is  assured  that  all  functions  are  accounted  for,  and  a  decision 
can  be  made  at  a  later  point  whether  to  automate  a  specific 
task,  or  assign  it  to  a  human  operator. 

TARDEC  found  this  approach  to  be  powerful  and  applied  it 
to  a  handful  of  projects  in  Fiscal  Year  2016,  to  help 
understand  and  characterize  the  system  operator’s  role  as  part 
of  the  larger  unit’s  objectives.  On  TARDEC’s  Autonomy  in 
Operational  Energy  project,  the  engineering  team  is  using  the 
Unit  Behavior  Model  developed  for  a  PLS  Truck  Company  to 
understand  the  operator  behaviors  beyond  the  physical 
operation  of  the  vehicle.  These  functions  are  being  cataloged 
to  ensure  that  a  future  autonomous  PLS  truck  is  able  to 
accomplish  all  of  the  behaviors  that  constitute  mission 
success,  not  just  the  obvious  ones  of  drive  from  point  A  to 
point  B. 

Another  example  of  the  Unit  Behavior  Model  in  use  is  on  a 
TARDEC  project  to  convert  the  three-person  crew  of  a 
Bradley  Fighting  Vehicle  to  a  two-person  crew.  The  Unit 
Behavior  Model  helped  the  engineering  team  identify  crew 
tasks  that  still  needed  to  be  accomplished,  but  did  not  directly 
involve  a  function  on  the  vehicle,  such  as  buddy  aid  medical 
tasks.  To  successfully  transition  from  three  crewmembers  to 
two,  the  engineering  team  needed  to  account  for  all  impacts 
to  removing  a  crewmember,  not  just  the  tasks  that  directly 
involved  the  vehicle  operation. 


LIMITATIONS  OF  THE  MODEL 

Development  and  use  of  the  Unit  Behavior  Model  is  an 
emerging  practice  in  TARDEC  and  as  such,  the  benefits  and 
limitations  are  still  being  studied.  The  processes  detailed 
above  has  shown  benefits  in  describing  the  larger  operational 
picture  and  influencing  technology  programs  with  the  art  of 
military  operations,  particularly  in  characterizing  the  Mission 
Command  elements  of  operations.  However,  the  process  is 
not  flawless  and  limitations  are  present. 

As  mentioned  before,  the  current  process  to  extract  data 
from  CATS  is  manual,  requiring  human  interaction  and  often 
line-by-line  manipulation  to  get  the  data  into  a  useable  or 
importable  format.  There  is  a  significant  opportunity  to 
connect  directly  to  the  database  behind  CATS  and  extract  task 
details  automatically,  enabling  real-time  traceably  of  the  Unit 
Behavior  Model  to  the  CATS  system  using  a  tool  such  as 
TARDEC’s  ISEF.  As  of  the  time  of  publication,  this 
opportunity  remains  an  item  of  interest  for  future 
investigation  as  TARDEC  continues  to  mature  this 
operational  analysis  process. 

Another  shortcoming  to  this  process  that  has  not  been 
completely  resolved  yet  is  providing  clear  guidance  and 
boundaries  on  how  far  to  trace  task  paths  in  CATS.  Most 
CATS  tasks  provide  a  list  of  other  supporting  or  supported 
tasks  that  are  associated  with  original  task.  These  supporting 
or  supported  tasks  could  be  either  collective  or  individual 
level,  and  some  tasks  have  upwards  of  50  other  tasks 
associated  with  it.  The  association  of  tasks  in  CATS  in  made 
in  the  general  sense,  without  respect  to  the  type  of  unit 
performing  the  task.  In  other  words,  a  Transportation  unit  may 
have  a  collective  task  of  “Break  Contact”  which  refers  to  the 
common  Break  Contact  task  where  Infantry  is  the  proponent. 
Break  Contact  could  feasibly  be  associated  with  another 
collective  task  such  as  “Conduct  an  Attack”.  While  this 
association  is  correct  in  an  agnostic  sense,  it  is  not  appropriate 
for  a  Transportation  unit,  which  would  never  execute  Conduct 
an  Attack. 

The  problem  gets  significantly  more  complicated  for 
maintenance  tasks,  such  as  “Conduct  Preventative 
Maintenance  Checks  and  Services  (PMCS)”.  Collective  and 
individual  maintenance  tasks  for  every  major  end  item  are 
associated  with  the  Conduct  PMCS  task.  However,  no  single 
unit,  at  the  company  level,  would  have  each  major  end  item 
within  its  TOE. 

Under  the  normal  training  use  of  CATS,  the  unit 
commander  would  apply  their  discretion  to  determine  what 
tasks  are  suitable  to  train  on  and  what  tasks  are  irrelevant. 
Using  CATS  in  the  engineering  environment  requires  a 
knowledgeable  expert  to  review  the  tasks  and  associated  tasks 
by  hand  to  determine  what  is  applicable  to  the  unit  being 
studied.  Doing  so  will  then  bound  the  number  and  scope  of 
the  tasks  to  be  manageable  by  the  engineering  team. 
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TARDEC  has  used  two  different  guidelines  to  help  resolve 
this  issue  uniformly,  depending  on  the  type  of  information 
desired  by  the  project.  The  first  set  of  boundaries  is  only  to 
look  at  tasks  associated  with  the  unit  METL.  With  these 
boundaries,  the  Unit  Behavior  Model  will  be  specifically 
focused  on  the  tasks  that  the  unit  must  be  highly  proficient  at 
to  complete  its  mission.  These  boundaries  produce  a  very 
manageable  task  set  suitable  for  manipulation  or 
accumulation  manually  in  Microsoft  Excel,  at  the  cost  of 
ignoring  non-METL  task  details. 

The  second  alternative  TARDEC  used  is  to  extract  all  the 
tasks  directly  referenced  in  CATS,  without  following  any 
associated  tasks  that  are  not  directly  associated  with  the  unit 
according  to  the  CATS  unit  task  list,  not  the  list  within  the 
task  itself.  This  extract  from  CATS  produces  a  complete 
picture  of  the  collective-level  tasks  for  the  unit,  but  is  too  large 
to  successfully  manage  in  a  simple  spreadsheet  and  requires  a 
database  or  architecture  tool  to  manage  the  data  and 
interactions  of  tasks.  Further  trimming  of  the  tasks  can  be 
done  within  a  tool,  such  as  Excel.  For  example  ignoring 
administrative  tasks  such  as  “Maintain  Unit  Strength”  in  favor 
for  tactical  tasks.  This  was  done  within  TARDEC  because  the 
scope  of  the  projects  relate  directly  to  tactical  tasks.  In  other 
organizations,  perhaps  one  where  the  Army’s  next  unit 
strength  software  is  being  developed,  it  would  be  more 
relevant  to  trim  tactical  tasks,  keeping  administrative  tasks 
applicable  to  the  technology  being  developed. 

Finally,  the  process  described  herein  does  not  fully 
eliminate  the  need  for  SME  support  to  execute,  although  the 
requirements  for  that  support  have  been  dramatically  reduced. 
Instead  of  requiring  a  20  year  veteran  within  the  specific 
specialty  of  the  project  to  act  as  the  project’s  operational 
expertise,  the  same  quality  of  work  can  be  provided  by  a  10 
year  veteran  with  general  combined  arms  experience.  Since 
the  source  data  for  CATS  is  verified  by  the  appropriate 
proponent,  the  only  SME  required  is  one  that  understands  the 


operational  language  in  CATS,  not  one  that  literally  has 
executed  the  tasks. 

SUMMARY 

Repurposing  the  CATS  task  repository  for  engineering 
purposes  is  a  tactic  that  is  still  under  development  and 
evaluation  within  the  S&T  environment.  However,  it  has 
shown  promising  results  in  delivering  operational  data  while 
limiting  the  amount  of  subject  matter  expertise  and  user 
knowledge  required.  Within  TARDEC,  the  Unit  Behavior 
Model,  derived  from  the  Operational  Task  Model,  has  been 
successfully  used  to  help  characterize  the  behaviors  of  vehicle 
operators  which  has  become  significantly  more  important  as 
the  Army  moves  towards  autonomous  systems  to  reduce 
human  error  and  mental  load. 

This  process  is  evolving  and  will  continue  to  mature  as  more 
projects  execute  it,  allowing  the  operations  research  team  to 
determine  its  suitability  at  solving  a  variety  of  operational 
issues  while  working  solutions  to  the  known  limitations.  Over 
the  past  year  the  process  has  been  used  at  TARDEC,  it  has 
been  successful  in  architecting  the  current  state  of  military 
operations  at  the  collective  company  level.  The  resultant 
products  from  the  models  developed  in  this  approach  are 
currently  supporting  three  major  TARDEC  initiatives.  While 
the  process  continues  to  mature  in  the  current  limited,  yet 
important  scope,  it  has  already  demonstrated  the  ability  to 
begin  to  fill  the  gaps  of  operational  knowledge  lost  in  the 
acquisition  workforce  over  the  past  20  years. 
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